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APPARATUS AND METHOD FOR FAIR MESSAGE EXCHANGES IN 
DISTRIBUTED MULTI-PLAYER GAMES 

RELATED APPLICATIONS 

The present invention is related to USSN 10/135053 filed on April 29, 2002 
5 and entitled Method and Apparatus for Supporting Real-Time Multi-User Distributed 
Applications and assigned to the assignee herein, the subject matter of the above 
application being incorporated herein by reference. 

FIELD OF THE INVENTION 

The present invention relates generally to communications networks, and more 
10 particularly to the support of real-time multi-user distributed applications on such 
networks. 

BACKGROUND OF THE INVENTION 

Real-time, multi-user distributed applications, such as online multi-player 
games or distributed interactive simulations (DIS), are becoming increasingly popular 

15 due to advances in game design and the availability of broadband Internet access to 
the end-user. Online multi-player games can be implemented either using the peer-to- 
peer model or the client-server model. In the peer-to-peer model players send their 
actions to each other and react on the received action, whereas in the client-server 
model all messages from players that carry their actions are ordered at a single server. 

20 In the peer-to-peer model, event consistency has been well studied using the concepts 
of logical clocks, causal ordering and total ordering in distributed systems. In the 
client-server model, consistency is automatically guaranteed because messages from 
all the players are only delivered at the central game server and, therefore, all 
messages follow both causal and total ordering. However, fairness in neither model 

25 has been addressed. Today most online multi-player games are implemented based on 
a client server model. This is due to the complexity of a peer-to-peer model based 
implementation as well as security restrictions that prevent peer-to-peer 
communication. The present invention focuses on games based on the client-server 
model. The design and implementation of such games should include an underlying 
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fairness property for the players. This is challenging, however, in cases where 
players, distributed over wide geographic areas, participate in a game together. 

In the client-server model, an authoritative game server is set up and all 
players or clients contact this game server to play the game against one another. The 
5 game server keeps track of the global state of the game. Players send their actions to 
the game server in messages referred to as action messages. The game server then 
processes the actions in sequence, changes the global state, and notifies players of the 
effects of their actions in messages termed state update messages or simply update 
messages. The state change that is communicated to the players may lead to more 

10 action messages being sent to the game server. The only communication in the 
system is between the game server and players. Players themselves do not send 
messages to one another, neither do they play any active role in deciding the ordering 
of actions in the game. Because of the real-time nature of online multi-player games, 
the majority of action and state update messages are sent over UDP; only a few 

15 messages are sent over TCP and only at game start-up. Because of this, applications 
have built-in mechanisms to handle message loss. For example, messages contain 
absolute location of objects instead of relative ones, therefore, there is no dependency 
on previous messages in case they are lost. 

Much of the focus on improving real-time, online multi-player games is on how to 
20 reduce player experienced response time. For timely state updates at player consoles, 
dead reckoning is commonly used to compensate for packet delay and loss. For client- 
server based first person shooter games, Y. W. Bernier, "Latency Compensation 
Methods in Client/Server In-game Protocol Design and Optimization," in Proc. of 
Game Developers Conference '0J , 2001, URL: 

25 http://www.gdconf.com/archives/p roceedings/200 l/prog\ papers.html discusses a 
number of latency compensating methods at the application level which are 
proprietary to each game. These methods are aimed at making large delays and 
message loss tolerable for players but do not consider the problems introduced by 
varying delays from the server to different players. 
30 Using the current best-effort Internet, players can experience erratic game 

progress that often prevents a player from responding effectively or appropriately. 
This can lead to player frustration, especially if the gaming environment is 
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competitive. In addition, because the game server is in charge of updating global 
states, and the network delay from the game server to different players is different, 
players may receive the same state update at different times. Furthermore, players' 
action messages can also take -different times to reach the game server, therefore 
5 unfairness in processing player action messages can be created at the game server. A 
player further away from the game server or connected to the server through 
congested or slower links will suffer from longer message delay. Because of this, 
even fast reacting players may not be given credit for their actions, leading to an 
unfair advantage for players with small message delays. 

10 SUMMARY OF THE INVENTION 

The Fair-Order Service of the present invention delivers action messages to 
the server as soon as it is feasible. Because action messages from different players 
exhibit different reaction times with respect to an update message, the Fair-Ordering 
Service executed at the server dynamically enforces a sufficient waiting period on 

1 5 each action message to guarantee the fair processing of all action messages. In reality, 
the waiting period at the server is bounded because of the real-time nature of 
interactive games. The algorithms that offer Fair Ordering Service take into 
consideration delayed and out-of-order action messages. When action messages 
corresponding to multiple update messages are interleaved, the Fair-Ordering Service 

20 matches the action message to the appropriate update message. It accomplishes this 
by maintaining a window of update messages and using the reaction times for an 
action message for each of the update messages in the window. This enables state 
changes at the game server to be performed with fairness to all the players. The Fair- 
Order Service invention is based on a framework that uses a proxy architecture 

25 making it transparent to any specific game application. The service is well suited to 
client-server based, online multi-player games, where a fair order of player actions is 
critical to the game outcome. 

BRIEF DESCRIPTION OF THE DRAWINGS 
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A more complete understanding of the present invention may be obtained 
from consideration of the following detailed description of the invention in 
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conjunction with the drawing, with like elements referenced with like references, in 
which: 

FIG. 1 (a) and (b) show exemplary embodiments of a distributed game 
environment; 

5 FIG. 2 shows an example of a state and its transition; 

FIG. 3 illustrates an exemplary message exchange between server and players 
in accordance with the present invention. 

FIG. 4 shows a fair order message delivery for state transitions shown in Fig. 

2; 

10 FIG. 5 shows an exemplary algorithm for fair-order message queuing in 

accordance with the present invention; 

FIG. 6 shows an example where messages arrive after their wait timeout; 
FIG. 7 shows an exemplary algorithm for fair-order message dequeuing in 
accordance with the present invention; 
1 5 FIG. 8 shows an example message sequence illustrating inconsistent views of 

a game between players; 

FIG. 9 shows a message sequence illustrating the fair-order message delivery 
service of the present invention; and 

FIG. 10 shows another message sequence illustrating the fair-order message 
20 delivery server of the present invention with out-of-order message reception; and 
FIG. 1 1 is an exemplary embodiment of a proxy device used in connection 
with the present invention. 

DETAILED DESCRIPTION 

The above mentioned unfairness problem is the focus of the present invention. 

25 Assuming that update messages are delivered to players at the same physical time, a 
fair order of message delivery would be one where action messages in response to 
these update messages are delivered to the server in the order in which they are 
produced by the players in physical time. This ensures that a player who reacted first 
to an update message by sending an action message will influence the state of the 

30 game before a player who reacted later. One earlier work on fair-ordering of action 
messages, the Sync-MS service by Y. Lin, K. Guo, and S. Paul, "Sync-MS: 
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Synchronized Messaging Service for Real-Time Multi-Player Distributed Games/' in 
Proc. of 10 th IEEE International Conference on Network Protocols (ICNP), Nov 2002, 
is based on a fairness definition for both state update messages and action messages. 
The Sync-MS service consists of two parts, Sync-out and Sync-in, where Sync-out 
5 delivers each state update message from the server to all players at the same physical 
time, and Sync-in at the server processes action messages in the order of the physical 
time they are sent. But in order to deliver messages to all the players at the same 
physical time, two main assumptions are made: (i) the clocks at all the players are 
synchronized and all these clocks are synchronized with the server clock as well, and 

10 (ii) the one-way delay from the server to each of the players can be accurately 
estimated. The above assumptions are required because an attempt is made to order 
action messages according to the physical time in which the players produce these 
messages. Further, this work does not consider the interleaving that may happen 
between action messages corresponding to multiple update messages and the effect of 

1 5 such interleaving on the state of the game that is maintained at the server. 

Without making the above assumptions, the same fair-order delivery effect 
can be achieved by delivering the action messages to the server in the order of 
increasing reaction time which is the time between the reception of an update message 
at a client and the sending of an action message in response to the update message. 

20 This removes the need to deliver update messages to all the players at the same 
physical time. Based on this idea, a novel network service is disclosed called Fair- 
Ordering Service, designed for client-server based, distributed, multi-user real-time 
applications such as online multi-player games. It addresses the issue of player action 
message fairness based on player reaction time. Note that the Fair-Ordering Service 

25 does not attempt to shorten network delays between the server and players but 
provides a framework that ensures fairness to players even when network delays are 
large and variable. Delay reductions could come from advances in CPU, link speed or 
game specific features, and therefore is orthogonal to a service that provides fair order 
delivery. 

30 Unlike existing techniques that use bucket synchronization mechanisms that 

depend on imposing a worst case delay on action messages, the Fair-Order Service of 
the present invention delivers action messages to the server as soon as it is feasible. 
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Because action messages from different players exhibit different reaction times with 
respect to an update message, the Fair-Ordering Service executed at the server 
dynamically enforces a sufficient waiting period on each action message to guarantee 
the fair processing of all action messages. In reality, the waiting period at the server is 
5 bounded because of the real-time nature of interactive games. The algorithms that 
offer Fair Ordering Service take into consideration delayed and out-of-order action 
messages. When action messages corresponding to multiple update messages are 
interleaved, the Fair-Ordering Service matches the action message to the appropriate 
update message. It accomplishes this by maintaining a window of update messages 

10 and using the reaction times for an action message for each of the update messages in 
the window. This enables state changes at the game server to be performed with 
fairness to all the players. 

The Fair-Order Service invention is based on a framework that uses a proxy 
architecture making it transparent to any specific game application. The service is 

15 well suited to client-server based, online multi-player games, where a fair order of 
player actions is critical to the game outcome. Examples of such games include first 
person shooter games like Quake, R. Swamy, "idSoftware Releases Quake 1 Source 
Code Under the GPL," URL: http://linuxtoday.eom/stories/ l 4 1 1 1/html., and real-time 
role playing games such as Dark Age of Camelot, Mythic Entertainment, "Dark Age 

20 of Camelot," URL: http: //www.darkageofcamelot.com. The game framework is 
clearly defined and its applicability in practice is illustrated through examples. 

MESSAGE EXCHANGE FRAMEWORK FOR DISTRIBUTED GAMES 

As discussed, the present invention relates to a network-based service for 
distributed multi-player games called Fair-Ordering Service. The service guarantees 

25 fair-ordering for action messages that are received at the server from all players in the 
game. The client-server based system consists of a game server 12 and a number of 
game players 14 (e.g., player devices) distributed over a network 10 as shown, for 
example, in Figure 1(a). The server sends state update messages to the players to 
inform them of the latest state of the game. Each player processes the update 

30 messages, displays the current state of the game and produces action messages based 
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on the reaction of the human player on the current state. Multiple action messages 
may be sent by a player in response to one update message. 

In order to perform the fair-ordering service, we introduce proxies for the 
server and the players, referred to as server proxy 16 and player proxy 18, 
5 respectively (Fig. 1(b)). The proxies could be co-located with the applications 
themselves, be part of the application or they could be one or more separate elements. 
Accordingly, when referring to proxy in the specification and the claims of the 
application it is understood that the proxy refers generally to the functionality of the 
invention and that the location of the proxy may be in any one of the above locations. 

10 As shown in Figure 1(b), both update and action messages are intermediated through 
the proxies. We assume that the network delay between proxies and their respective 
server or player is negligible. 

The invention takes into account the most general distributed environment 
where (1) the underlying network transport may not guarantee any desired ordering of 

15 message delivery from multiple sources, (2) messages from the same source may 
reach their common destination out of order, or may get lost in transport, and (3) the 
individual players and the game server do not have their clocks synchronized. 

As will be explained in greater detail herein, the server proxy receives update 
messages from the game server, tags them with message numbers and sends them to 

20 the player proxies. It receives action messages from the player proxies, orders them to 
ensure fairness based on the additional information with which the player proxies 
augment the action message, and delivers them to the game server. The player proxy 
-receives update messages from the server proxy and delivers them to the players. In 
the other direction, it tags the action messages sent by the players with the appropriate 

25 information as described herein, and sends them to the server proxy. Notice that in 
the described exemplary embodiment the proxies are completely transparent to 
specific games; that is, they are not aware of the semantics of a particular game. 

State and State Transitions 

The state of a game at the server is defined to be a set of objects and their 
30 positions. A state transition takes place when there is a change in the set of objects or 
the positions of the objects. State update messages are sent by a server periodically to 
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the players either to inform the player of a state transition or simply the current f 
positions of the objects. The interval between two consecutive update messages sent 
by the server is typically 40 ms for real-time video display at 25 frames per second. 
For simplicity, the examples set forth herein only illustrate state transitions where 
there is a change in the set of objects. 

Figure 2 assists in illustrating the definition of state transition. The initial state 
of the game Si shows three aircraft ACj, AC 2 and AC 3 . An update message UMi is 
sent to the players with this state information at time U"i- The next state S2 shows 
only aircraft AC 1 and AC3. AC2 has been removed because of an action message that 
the server received from some player. An update message UM 2 is sent at time U2 to 
notify the players of the state transition. State S3 shows aircraft ACi and AC 4 . 
Aircraft AC3 has been removed and aircraft AC4 has been included. A corresponding 
update message is also sent to the players. Thus, a state transition involving change 
of objects, not positions, may be due to one of the following reasons: (a) removal of 
objects, (b) inclusion of objects, and (c) removal as well as inclusion of objects. A 
state change always leads to an update message being sent. 

Fair-Order 

Let us now examine the message exchanges between the server and the 
players and their effect on the state of the game. Figure 3 shows a timing diagram of 
20 an instance of message exchange between the server and the player Pj Let £/, denote 
the server's local time at which the server sends an update message UMi . Player Pj 

receives UMi at its local time R'j . After receiving an update message, the player acts 
on it, which in turn generates an action message. We refer to the duration between 
reception of an update message and transmission of an action message by a player as 

25 reaction time. AM' jk denotes the action message sent by player j at its local time 

A l jk after acting on UM t from the server. Let S' Jk = A' Jk - Rj denote the corresponding 
reaction time. For each update message, the Fair-Ordering Service delivers player 
action messages (corresponding to that update message) to the server in an increasing 
order of the reaction times. 



10 
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Consider Figure 3 again and assume the message exchanges are between the 
proxies for both the server and player Pj. Let -> denote the delivered before 
relationship between two messages. Then, fair-order delivery will need to satisfy the 
following three conditions. 

Fair Order Conditions 

1) For update message UM t and player P J9 AM' Jk -> AM^^ for all k 9 

and / > 0. That is, all action messages produced by a player in response to an 
update message are delivered to the server in the order in which they were 
produced, and 

2) For update message UMi and players Pj and P n9 AM' jk A M ' nJ , for all 

j, K I and n * j , if {Sj k = A jk - Rj ) < (<5^ = A^ f - K n ) . That is, action messages 

from two different players corresponding to the same update message are 
delivered in increasing order of reaction times, and 

3) For update messages UM a and UM a+x , x> 0, AM a jh AM^ X for 

all j, k t n and /. That is, all action messages produced in response to an update 
message from all players are delivered to the server before delivering action 
messages that are produced in response to an update message that was sent 
later. 

In an ideal distributed game environment where all players have a 
synchronized clock and message delivery over the network takes the same amount of 
time for every player, fair-order can be achieved if the action messages from the 
players are ordered based on the physical times at which they are generated. It is easy 
to see that in this ideal situation, such ordering would result in the action messages 
being ordered in an increasing order of reaction times. In practice, however, neither 
the players' clocks are synchronized nor the delay in message delivery is the same or 
even known a priori. The fair-ordering requirements enumerated above provide fair 
processing of the action messages without these assumptions. In essence, for game 
applications it makes sense to award a player with the fastest reaction time, and the 
Fair-Ordering Service ensures that. 
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Referring to Fig. 4, an example of the Fair-Ordering Service in accordance 
with the present invention is illustrated. The fair-order message distribution and the 
state changes happen in the server and players Pj and P2. The server and player 
proxies (not shown in the Figure) work transparently to the server and the players to 
5 ensure fair-ordering of the messages. When the state of the game is Sy, update 
message UMj is sent by the server and received by both players. Players may receive 
UMj at different instants of local time (that is, Rl * R\ ) due to variability in network 
conditions. As noted previously, they run independent clocks that may neither be 
synchronized with each other nor with the game server. Pj sends an action 

10 message AM\ X = ( Remove AC 2 ) , which is received at the server proxy with reaction 
time Sji . /^also sends an action message AM X 2X = (Remove AC 2 > with reaction 

time 8 2 \ > S x \ . The server proxy receives both action messages, and inspection of the 
reaction times reveals that player Pj has acted on state S2 of the game quicker than 
player P 2 . Therefore, the action (Remove AC 2 > is attributed to P/, not to P 2 , 

15 regardless of the relative arrival order of AM\ X and AM 2X . With Fair-Ordering 
Service, the server delivers A M x u from Pj to the server first. Note that Figure 4 
depicts the delivery instances of action according to fair order. The server acts on this 
message and AC 2 is removed. This action message changes the state to S2 and update 
message UM 2 is sent at time U 2 . When the action message AM\ X from P 2 is 

20 delivered and processed at the server, it will be done with respect to state S 2 .As AC 2 
has already been removed and is not part of state S2 , this action message leads to no 
operation being performed by the server. Pj collects credit for removing AC 2 , but P 2 
does not, therefore fairness is ensured. 

Now assume that UM2 reaches the players and they send action messages 

25 AM XX =( Remove AC 3 , Add AC 4 ) and AM 2X =( Remove AC X ), respectively with 

reaction times S x \ < S 2X . Again with Fair-Ordering Service, AM XX is processed first, 
AC 3 is removed and AC 4 is added. The state is changed to S3 and update message UM 3 
is sent at time U 3 . AM 2 21 processed next on state S3 and ACj is removed and the state 
changes to S4 and update message UM 4 is sent. Notice the sequence of state changes 
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is reflected in Figure 2. In the following section we describe a suite of algorithms that 
guarantees fair-order delivery of action messages to the server. 

FAIR-ORDERED MESSAGE DELIVERY ALGORITHMS 

When a server sends the /'* update message £/M ; . to the players, the server 
5 proxy records the sending time U i , and tags it with the update message number i or a 
function thereof. Similarly, when the proxy for player P. receives this message, it 
records in R'j the reception time for this message. Further, when the k ih action 
message is sent at time A' Jk in response to the i th update message, the player proxy 
uses A' jk to calculate S' Jh . The player proxy sends the action message along with the 
10 following information tagged to the message: (a) the update message number, i 
corresponding to this action message, (b) the reaction time S' Jk , and (c) the N' Jk action 

message number, where all of the above may also be functions or some other 
representation corresponding the values to be indicated. The action messages are 
numbered in an increasing order starting from 1 and the numbering scheme spans 
15 different update messages. That is, if the last action message from a player 
corresponding to update message t/M, is numbered m, the first action message from 
the same player corresponding to update message UM M will be numbered m + 1 . 
This numbering system is used in delivering messages in order. Thus, update message 
UM i from the server will be tagged with /at the proxy server and action message 

20 AM l jk from player P. will be tagged with the three tuple (/,£j A ,A^). As would be 

understood, other numbering systems used to convey similar information may also be 

used. Because message number N' jk is used to deliver action messages from the same 

player in sequence, we do not need to consider it until we consider action messages 
that arrive out of order. 

25 At the server proxy, the expected round-trip time (excluding any reaction time 

at the player, of course) to each of the players or player proxies is computed using 
some standard algorithm such as for TCP. We denote by Wj the wait timeout value 
for player P. . The calculation of the round-trip time is independent of the message 
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delivery algorithm. Let rttj be the expected round-trip time from the server proxy to 
proxy for player P. . An exponential averaging algorithm can be used to update the rtt 
based on the round-trip that is seen for a particular message as follows: rtt„ ew = (1-a) 
x rtt 0 id + a x mensem, where rtt new is the updated rtt, rtt 0 id is the rtt that was calculated 
5 before, rttcurrem is the rtt for the current message and a is an exponential averaging 
factor where 0 < <x< 1. In order to account for variances in round-trip time, the 
maximum amount of time that the server proxy will wait before timing out on an 
action message from a player will be some multiple of the round-trip time. Let Wj 
denote this wait timeout value for player Pj . Thus, Wj = b x rttj , where b > 1 is some 
10 constant. 

When an action message is received at the server proxy, it is queued to be 
delivered to the game server; before it is queued, the following parameters are 
computed: (a) the position in the queue where this message should be inserted and (b) 
the local time at which the message is to be delivered to the game server. Every time 

15 an action message arrives, this arrival can lead to the re-computation of both the 
current position and the delivery time of messages in the queue. The relative position 
of the messages (i.e., position with respect to on another) already in the queue will not 
change, but their absolute positions may change because the arriving action message 
may be inserted anywhere in the queue. The delivery time of the messages may 

20 change and this change will always lead to the delivery time being shortened. These 
are properties of the fair-ordering message delivery algorithm described below. Note 
that the definition of fair-order delivery is only valid for messages arriving within 
their wait timeout values. An approach to deal with messages with network delay 
larger than their wait timeouts is discussed herein. 

25 Position of a Message in the Delivery Queue 

When an action message AM' jk arrives at the server proxy, it is inserted into 
the delivery queue and the location where it is inserted is based on the values i and 
Sj k . The delivery queue is kept sorted based on the two tuple (i,S) with the key i 
first and then the key S . Thus, an action message with the tuple (2, 3) will be 

30 positioned before another action message with the tuple (2, 4) and the action message 
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with the tuple (2,4) will be positioned before another action message with the tuple (3, 
2). This means, the messages are sorted in the ascending order of their corresponding 
update message ids and within the set of action messages corresponding to an update 
message, they are sorted in the ascending order of the reaction times. Note that when 
5 an action message arrives, it can be inserted anywhere in the queue and the relative 
positions of the existing messages in the queue do not change. The message delivery 
algorithm has the following main property. 

Property 1: If the delivery queue is sorted based on the tuple (i 9 S) with the 

key i first and then the key S , then fair-order delivery is ensured if the 
10 messages are delivered in the order they are found in the delivery queue. 

The above property holds because sorting and delivering messages based on 

(/, S) satisfies all three conditions of fair-ordering. Sorting the messages in the order 

of the update message ids (e.g., /) ensures that fair-order delivery Condition 3 is 
satisfied. In addition, further sorting the messages corresponding to an update 
15 message, using reaction times ensures fair-order Condition 2 and Condition 1. Note 
that the action message number (N) carried by the action message could have been 
used to ensure Condition 1, but it is not necessary since sorting action messages 
according to reaction times trivially ensures Condition 1 . 

Computation of Delivery Time of a Message 
20 When an action message corresponding to an update message arrives at the 

server proxy, the algorithm shown in Figure 5 is executed to insert the message into 

the delivery queue. The first step is to compute the delivery time D(M k ) of the 
action message Mk to the game server. Delivery time is computed such that any action 
message that may arrive out of fair-order at the server proxy is delivered to the game 
25 server in fair-order. In order to achieve this, messages may be queued in the server 
proxy and delivered according to the delivery time. We will show later (in Properties 
2 and 3) that execution of step 2 of the algorithm does not modify the relative order of 
the messages that are already in the fair-ordered delivery queue. The delivery time of 
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the existing messages are recomputed in step 4 only to deliver them earlier than their 
previously computed delivery time (refer to Property 3 herein). 

We detail the procedure to compute the delivery time of a message in the 
following three sections. In a first section we assume that messages arrive at the 
5 server proxy in the order in which they are sent by the player and within their wait 
timeouts. A next section augments the previous section with messages arriving out of 
order but within their wait timeouts and a later section presents the most general case 
when messages do not arrive within their wait timeouts. 

1) Messages arrive in order and within their wait time-out: Consider a set 
10 of action messages that have been received at the server proxy in response to update 
message UM i and have been fair-ordered and put in the delivery queue according to 
their reaction times. Let these action messages in the fair-ordered queue be 
M,,M 2 ,..., M n . Let D(M k ) denote the delivery time of action message M k and 
P(M }9 M 2 ,...,M n ) denote the set, which represents the union of all the players who 
15 sent messages M x ,M 2 ,...,M n . Let S k denote the reaction time for message M k . 
Since M k 's are fair-ordered, S x <5 2 <...<S n . Let T denote the set of all players. 
Then, the earliest possible delivery time for a message in the queue, based on 
messages arrived so far, will be as follows. 

Definition 1 : Computation of delivery time with in order message arrival and 
20 within their wait timeouts: Delivery time of message M k , 1 < £ < w , in the fair- 

ordered queue is D(M k ) = U, + max { JeT ^ {MkM ^ M} {W J } + S h . 

Note that ordering the messages and delivering them according to their reaction times 
will ensure fair-ordering delivery of messages only if it is guaranteed that when an 
action message corresponding to an update message is delivered, no other action 
25 message corresponding to the same update message with a smaller reaction time may 
be in transit. Consider message M x . The update message UM i corresponding to this 
action message was sent at time U i . The reaction time for this message is S x . Since 
we assumed messages arrive within .wait timeout, if a message from another player P y 
corresponding to update message UM i with a reaction time smaller than S } is to arrive 
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at the server proxy, it needs to arrive by time £/,. + Wj + S x . Considering all players, 
for a message with a reaction time smaller than S x to arrive from any player 



arrival ensures that action messages arrive at the server proxy in the order in which 
they are sent. This means no action messages from P(M X9 M 29 ... 9 M n )can be received 
with a reaction time smaller than S x given that action messages from all these players 
have been received with reaction times larger than or equal to S x . That means, only 
players from whom no action message has been received need to be considered. Thus, 

~^ max {j^r-p(M i M 2 ^M n )} + • * n 8 enera ^ f° r M k 9 no action messages 
from P(M k9 M k+X9 ... 9 M n )can be received with a reaction time smaller than S k given 
that action messages from all these players have been received with reaction times 
larger than or equal to 8 k . Note that in this case, it is possible that another action 
message is received from P(M X9 M 29 „. 9 M k _ x ) with a reaction time smaller than S h . 
Then, there are only two sets of players need to be considered. One set is the players 
from whom no action messages have been received which are T — P(M X9 M 29 ... 9 M n ) 9 
and the other is P(M l9 M 29 ... 9 M k _ x ) . This justifies the above definition. 

It is necessary to ensure that the delivery times of messages computed using 
the above definition are consistent with the order in which the action messages are 
ordered in the delivery queue. If the delivery times satisfy this we call it a feasible 
delivery order. The delivery time computation defined above does lead to a feasible 
delivery order as argued below. 

Property 2: Property of delivery time where messages arrive in order and 
within their wait timeouts: Message delivery time 

sequence D(M l ) 9 D(M 2 ) 9 ... 9 D(M„) 9 is a feasible delivery order. 
The above property holds because of the following reasoning. Since 
M X9 M 29 ... 9 M n are fair-ordered, 5 X < S 2 < . . . < 5 n holds. Also notice that 



(including P(M X )) 9 it needs to arrive by time 




But in order 
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maX { J rer-/>(A/ l ^ 2 ,.^„)} { W j} * m ZX{jeT-P(M 2 M 2 ,..M n )} { W j} ~ "' 

Therefore, D (M l ) < D (M 2 )<...< D (M n ) . Thus the property follows. 

The above property illustrates that given action messages, it is feasible to 
achieve fair-ordered delivery at the server by queuing them in fair-order at the server 
5 proxy and delivering them to the server according to their respective delivery times. 

Definition 2: Recomputation of delivery time where messages arrive in order 
and within their wait timeouts: Suppose an action message 
M p ,p>n 9 S k <8 p <S k+l , is inserted into the delivery queue M l ,M 2 ,...,M n 
conforming the fair-order. Then the delivery times of M X9 M 29 ... 9 M p _ x are 
10 recomputed as, D" ew (MJ = D(M m )-0 m ,l <m<p where 

D(MrJ does not change, therefore Lf eyv (Mn) = DfMJ. 

Note that the computation of the delivery time of M p with reaction time 8 , 
and recalculation of delivery times of M 15 M 2 ,..., M n are straightforward from 
15 Property 1 and Definition 1. Since 5 k <5 p <S k+] , according to Property 1, M p is 
inserted between M k andM^ +1 in the delivery queue, and the new message order 
becomes M l9 M 29 ...,M k9 M p9 M h+]9 ... 9 M n . Since the message order has changed, 
following Definition 1, D weM '(M / ) we compute the new delivery times for 
message M t , 1 < / < n + 1 , as follows: 



20 



Z>-(A/ I ) = £/ I + max {^} + $ 

{jeT-P( Mi ,M 2 , -Mt M p M k . x M n )} 

D"~(M 2 ) = U i+ max {Wj} + S 2 

\jeT-p{M lr ..M k ^l p M M ,.M„)} 



D" e \M k ) = U i+ max {Wj} + 8 k 

\jeT-P{M t M p M^ M„)} 
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D"™(M p ) = U i + 



max 




{j B T-P(M p ,M Mr .^M m )} 



D-(M k+l ) = U i + 



max 



{ 7 er-/»(M t+1 ,...^„)} 



D ne \M„) = U i + 



max 




It can be observed that when a newly arrived message is inserted into the 
delivery queue, the delivery times for messages behind it are not changed. The 
delivery times for messages ahead of it either shorten or do not change. This is 
because the set of players whose wait timeout values are considered in the formula 
decreases by one, i.e., P(M p ) . The algorithm, as it is specified, requires that the 
delivery time of all messages ahead of the newly arriving message be recalculated 
every time a message arrives. Arrival of every message could potentially shorten the 
delivery time of every message ahead of it and hence make the game progress faster. 
But this computation is not required to maintain feasible delivery order. If it is 
observed that the overhead of recomputing the delivery time is high, the recalculation 
could be performed after the arrival of a number of messages (rather than every 
message). This would require information to be kept about all the messages that arrive 
within two such recalculations and apply this information when recalculation is 
performed. The tradeoff between processing overhead and delayed message delivery 
can be adjusted by properly choosing the number of message arrivals to wait before 
recalculation. The delivery times of the action messages ahead of it can be 
incrementally updated as defined in Definition 2. 

Property 3: Property of recomputed delivery time when messages arrive in 
order and within their wait timeouts: If the message delivery time sequence 

D(M 1 ),£)(M 2 ),...,Z)(M /J ) is a feasible delivery order and a newly arrived 

message M p is fair-orderly inserted between M k and M k+l , then the 

sequence of recomputed message delivery times, 
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D new (M x ),D new {M 2 ),...,D new {M n ),D n ™ remains a feasible delivery 

order. 

The above property holds because of the following reasoning. Since message 
delivery time D(M r ),l < r < n, is in a feasible delivery order, we know that 
5 D(M } )<D(M 2 )<- <D(M k )<D(M k+x )< -<D(M n ). We also know that 
D new (M m ),l <m<p, are the only deliver times that may have changed and may be 
different from D(M m ),l < m < p due to the fair-ordered insertion. Since 
D new (M m ),l <m< p are computed using Definition 1, we know from Property 2 that 
D new (M x )<D new (M 2 )< ... <D new (M k )<D" ew (M p ). Since D" ew (M m ),k + l < m < n 
10 are the same as D(M m ), k + \ < m < n , we also know 
*a.Zr»(M,„)<Z)«-(M M )<... £D -(K). Since nax,,.^, ^{rji 

max ^r-^ +1 ,..^ )} {Wj} , we note that (M p ) < D"™(M k+l ) and that 
E > (Mk + i) = D {M k ). Thus we conclude 

that D new (M 1 ) < D" ew (M 2 ) < • • • < D new {M k ) < D" ew M p < D(M k+l )<--<D(M„). This 

1 5 means that the feasible delivery order is still maintained for the recomputed message 
delivery times. 

The above property establishes the fact that if the server proxy keeps the 
message delivery queue always sorted according to the fair order, and recomputes the 
delivery times of the affected messages due to the insertion of a newly arrived 
20 message, the fair-order delivery of messages to the game server can be ensured. 

2) Messages arrive out of order but within their wait timeouts: Let us 
now consider the situation where action messages from a player can arrive at the 
server proxy out of order. The action message numbers carried in the action messages 
are now used to (1) order the messages from a specific player and (2) when a message 
25 arrives determine whether all earlier messages that were sent by the same player have 
already arrived. When messages arrive, they are fair-ordered in the delivery queue 
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based on their reaction times as before, but now, delivery times are computed 
accounting for the fact that messages may arrive out of order. 

Assuming that the delivery queue contains messages M,, M 2 ,...,A/ W in that 
order, let Q(M l9 M 29 ...,M n ) denote the subset of messages within M x ,M 29 ...,M n 
which are sequenced in the sense that all messages from the players 
P(Q(M l ,M 2 ,...,M n )} that were sent before have already been received and have 

either (a) been delivered to the server or (b) been placed in the delivery queue. Then 
the delivery times will be computed as follows. 

Definition 3: Computation of delivery time with messages arriving out of 
order but within their wait timeouts: Delivery time of message M k ,\< k<n, 



This definition follows similar reasoning as Definition 1 . The only difference 
here is that the delivery time of message M k must consider the possible arrival of out 
of order messages with smaller reaction times than S k for all messages that are not 
sequenced. 

The following property ensures that delivery times, as computed above, lead 
to a feasible delivery order. 

Property 4: Property of delivery time when messages arrive out of order but 
within their wait timeouts: Message delivery time sequence 

D(M } ),D(M 2 ),...,D(M n ), is a feasible delivery order. 

This property can be shown to hold following reasoning similar to those for 
Property 2. The delivery times of the messages after the insertion of the new message 
can be computed using procedure similar to the previous case. Further, it can be 
shown that the newly computed delivery times will satisfy a feasible delivery order 
using reasoning similar to that used for Property 3. 



in the fair-ordered queue is D(M k ) = £/,.+ max 



{jeT-P(Q(M k M k+i ,-M„))} 



3) Messages do not arrive within their wait timeout: Let us now consider 
the situation when messages may arrive after their wait timeout. Consider the example 
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shown in Figure 6 with two players P x and P 2 . The sequence numbers of messages 
are shown below the messages. In Figure 6(a), the delivery queue is shown with 
messages M x , M 3 and M 4 from P x and M 2 from P 2 . Assume that the message from 
P x with the sequence number 101 has not arrived yet. Consider message M 2 from P 2 
5 . With respect to this message, M 3 and M 4 are not sequenced according to the 
definition of Q given previously. 

Assume that the delivery time for M x is reached before the message with 
sequence number 101 from P x arrives. This means, the wait timeout value for this 
message has been exceeded. Message M x will be delivered and the message with 

10 sequence number 101 will be marked late and delivered to the game server 
immediately when it arrives. The server proxy could also drop late messages. 
However, as the server proxy is not aware of game semantics, it may be more 
appropriate for the server proxy to deliver the message to the game server and let the 
game server decide how to process it. 

15 When M x is delivered, messages M 3 and M 4 will become sequenced with 

respect to M 2 as shown in Figure 6(b). This means, the delivery time of M 2 needs to 
be recomputed. That is, when messages can arrive after their wait time-outs, delivery 
times of messages in the queue need to be updated even when messages are delivered 
in addition to being updated when messages arrive (for the cases when messages 

20 arrive within their wait timeout, as described in previous sections, delivery times have 
to be updated only when messages arrive). In this case, the computation of delivery 
times is exactly as indicated in Definition 3 when messages get delivered as well as 
when messages arrive. Property 4 holds for this case as well, except when the 
message at the head of the queue is delivered, recomputation of delivery time is 

25 needed for all messages in the queue. We add the dequeuing algorithm presented in 
Figure 7 when messages do not arrive within their wait timeout. When a message with 
sequence number 101 arrives, it will be tagged as a late message and delivered 
immediately to the game server. As it had already been marked as late and delivery 
times of the messages in the queue had been updated based on this, no recomputation 

30 of delivery times is needed at this point. 
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4) Correlation of action message delivery time: So far we have computed 
the delivery time of action messages corresponding to an update message UM i in 
isolation, that is, without considering the delivery times of the action messages 
corresponding to update message f/Af f ._, . The delivery queue is kept sorted based on 
5 the tuple . Action messages are delivered to the game server in this order. That 
is, all action messages corresponding to update message UM^ are delivered before 
any action message corresponding to update message UMj is delivered. This 
correlated decision overrides the delivery times computed for an action message 
considering the corresponding update message in isolation. 

10 The game application must define what all action messages corresponding to 

an update message signify. Action messages corresponding to an update message can 
arrive at any time and assuming that players can send any number of action messages 
per update message, a determination must be made when not to accept any more 
action messages corresponding to an update message. Let us assume that this decision 

15 is made based on some technique determined by the game application. When this 
determination is made for update message UM^ let us assume that the delivery time 
computed for the last action message Z ; _, corresponding to t/M,., in the delivery 
queue to be . Any action message corresponding to UM t _ x that arrives after 
has been delivered will be dropped. Of course, any action message corresponding to 

20 UMj_ x that arrives at the server proxy before is delivered, and is deemed to be 

delivered before will be delivered. Let D l (M,),D' (M 2 ),..., D i (M n ) denote the 
delivery times of messages M x ,M 2 ,...,M n that are in the delivery queue and 
correspond to update message UM^ Then, the delivery time of message 
M k ,\< k <n, as computed in the previous section must be modified as: 

25 Z)'(MJ = max {,,_,, tf,+ma^^ This ensures that all 

action messages corresponding to update message UM t _ x are delivered before any 
action message corresponding to update message UM S is delivered. Note that the 
delivery times computed above can change due to both message arrivals and message 
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deliveries. The change could be (a) due to a change in t gmm} , which could be due to the 
arrival or delivery of an action message corresponding to update message UM i-x or 
earlier update messages, or, (b) due to an arrival of an action message corresponding 
to update message UM i which will lead to a change in the second component on 
5 which maximum is computed. 

FAIRNESS AMONG PLAYERS WITH INCONSISTENT VIEWS 

The fair-ordered message delivery algorithm described previously assumes 

that when an action message is sent by a player proxy, it carries the tuple (i,S) where 
/ is the update message id of the most recent update message UM i received at the 

10 player. In our discussion of the algorithm, we implicitly assumed that all players 
receive UM i , update their states and then send the action messages corresponding to 
UM i . In practice it may so happen that a new update message UM M sent by the 
server does not reach a set of players or is delayed compared to the rest of the players. 
Therefore, the players with the most up-to-date information send all their action 

15 messages tagged with update message id / + 1 by the player proxies, whereas the 
remaining players send action messages tagged with the previous update message id i. 
This situation, where action messages and update messages cross each other, may lead 
to unfairness among the players. The unfairness arises due to the inconsistency in the 
view of the game that each player possesses. We first describe the problem with the 

20 help of an example and then describe the steps taken in the fair-ordered message 
delivery system of the invention to overcome this. 

Consider the same example shown in Figure 2, with a slightly different update 
and action message sequence than the one in Figure 4. The message sequence is 
shown in Figure 8. Assume that when UM X is received, players P x and P 2 send action 

25 messages AAt\ x = (Re move AC 2 ) and AM\ X = (Re move AC 2 ) , respectively, with 

S 2 \ > 5 X \ . AM\ X gets delivered (when its delivery time is reached) by the server proxy 
to the game server. The server changes state to S 2 and sends update message UM 2 . 
Assume that UM 2 reaches P 2 but does not reach P x . At this time, the state according 
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to P x is S x and the state according to P 2 is iS 2 . Assume now that both P x and P 2 send 
action messages AM\ 2 = (Re move A C 3 , Add A C 4 ) , and 

^Af* = (Remove AC 3 , Add^C 4 ). Note that AC 3 is part of both S x and S 2 . The 
action message from P x will carry the tuple (l^^and that from P 2 will carry the 
5 tuple (2,S 2X ) . The reaction time S\ 2 has been computed to be the interval between the 

time UM X is received at P x to the time AM\ 2 was sent by P x . The reaction time S 2X 
has been computed to be the interval between the time UM 2 is received at P 2 to the 
time AM 2X was sent by P 2 . Thus, these two reaction times are not directly 
comparable although it is possible that if the reaction times of both the players had 
10 been compared from the time each received UM X , P 2 had a faster reaction time. The 
way the algorithm is described, given that all action messages corresponding to 
UM X will be processed before any action messages corresponding to UM 2 , P x 's action 
on ^4C 3 and AC 4 will be processed before P 2 's action on AC 3 and AC 4 , thus being 
unfair to P 2 . 

15 To remove this unfairness, when action messages are sent by players, a set of 

tuples are tagged onto each of these action messages by their proxies each 
representing the reaction time from the time a set of update messages are received. 
The set of update messages, which we refer to as the window, for which this 
information needs to be sent is indicated by the server proxy when it sends an update 

20 message. In the above example, when P x and P 2 send action messages AM\ 2 and 
AM 2X , respectively to remove AC 3 and add AC 4 , P x sends the tuple (l,^) because 
it has seen only UM X when it sent this action message, but P 2 sends both tuples 
(l,£ 22 ) and (2,^). That is, P 2 indicates that it is sending this action message with a 

reaction time of 8 \ 2 from the time it received UM X and a reaction time of S 2X from 
25 the time it received UM 2 . At the server proxy, message splitting is performed. The 
action message sent by P x is put in the delivery queue with the messages 
corresponding to UM X and is fair-ordered based on S] 2 but the action message from 
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P 2 is split and inserted in two places, one with the messages corresponding to UM X 
where it is fair-ordered based on S y 22 and the other with messages corresponding to 
UM 2 where it is fair-ordered based on S 2X . If. S\ 2 is smaller than S\ 2 , the action 
(Remove AC 3 , Add AC A ) from P 2 is delivered to the game application before the 
5 action (Re move AC 3 , Add AC 4 ) from P } . 

A question may be raised as to why the action message from P 2 was split and 
put together with the action messages corresponding to update message UM 2 as well. 
This is because, the server proxy can only relate the action and update messages, but 
has no idea about the semantics of the action that is being performed - as it is 

10 transparent to the game application. Because of this, it has no choice, but to put the 
action message from P 2 together with action messages corresponding to UM 2 as well. 
When the "split" messages are delivered by the server proxy to the game server, it a) 
indicates that this is a "split" message and b) provides the correspondence between 
this action message and the update message to which this action message was 

15 mapped; from this, the game server knows the state to which the action message 
should be applied. Given this, the redundant "split" message should lead to a "no 
operation" when it is delivered and processed by the application running on the game 

server, as the action (Re move AC 3 , Add ^4C 4 ) has already been performed by the 

game server. Note that the game server can filter out redundant copies of "split" 
20 messages once it knows that a message is a "split" message irrespective of the actions 

specified in the message. 

It should be noted that action messages forwarded by the server proxy to the 

game server do require extra information to be tagged. Examples of such information 

include the update message number corresponding to the action message as well as 
25 information about whether a message is a late message or a "split" message. Because 

application specific information does not need to be passed in these messages, the 

fair-order algorithms are game application transparent. 

We mentioned that a window of update messages for which reaction times are 

needed is indicated by the server proxy to the player proxies. This window is based on 
30 the determination by the server proxy about when to stop accepting action messages 
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corresponding to a particular update message. In the example, when UM 3 is sent by 
the server proxy, if it is still accepting action messages corresponding to UM X , which 
means it still has not delivered the last action message corresponding to UM X , it 
indicates the window to be [UM X , UM 2 , UM 3 ] . If it has already delivered Z,, it 
5 indicates this window to be[UM 29 UM 3 ], Determining the size of the window is an 

open issue. As would be understood, the game server's application can help in this 
regard. 

EXAMPLES 

Let us consider an example, which illustrates the fair-order message delivery 
algorithms of the present invention by showing the computation of the delivery times. 
Let us take the example shown in Figure 8 and add timing information to it. The 
resulting figure is shown in Figure 9. The timing information shown is in terms of a 
logical clock. The delivery queue at the time of specific events is shown in the figure, 
on top of those events. State changes trigger update messages to be sent and for the 
purpose of timing calculations, it is assumed that these messages are sent 
instantaneously after a state change. 

Referring to Figures 8 and 9, the game session consists of two players P x and P 2 
and a Server. We use D' {^AM' jk } to denote the delivery time for action message 
AMj k corresponding to update message UM i . Assume that the wait timeouts for the 

two players are W x = 10 and W 2 -\5. The following describes the various sequences 
in the game according to the present invention as illustrated in Figures 8 and 9. 

1) At time 100, the state of the game is S x which consists of objects AC X , AC 2 and 

AC 3 . Update message UM X is sent by the server informing the players of this 

25 state. The window sent is [UM X ]. UM X is received at P x and P 2 . They send 

action messages AM\ X and AM\ X . The tuples sent with these messages are (1, 
4) and (1, 3) respectively. 



10 



15 



20 
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2) AM\ X is received at the server proxy (and has arrived in order which is verified 
by looking at the sequence number), and is put in the delivery queue. According 
to Definition 1 , its delivery time is calculated as D l (AM x xx ) = 1 00 + 15 + 4 = 119. 

3) AM\ X is delivered to the server at 119 and credit for removing AC 2 is given to 
P x . Any action message corresponding to UM l with a reaction time equal to or 
smaller than 4 that is received later will be dropped (such a message will be 
received only if it reaches after its wait timeout). The state of the game is 
changed to S 2 which consists of the objects AC X and AC 3 . The update message 
UM 2 is sent to the players. The window sent is [UM X ,UM 2 ] 

4) AM 2 \ is received at the server proxy. This message has a reaction time smaller 

than the reaction time of an already delivered message corresponding to UM X 

and is dropped. UM 2 is received at P 2 but is lost on its way to P x . Action 

messages AM\ 2 and AM 2l are sent by players P x and P 2 . AM\ 2 carries only 

the tuple (1, 30) as UM 2 was not received at P x . AM 2X carries the tuples (1, 37) 
and (2, 9). 

5) AM\ 2 is received at the server proxy. This message has arrived in order and so 
the delivery time for this message is calculated as 
D x (AM\ 2 ) = 100 + 1 5 + 30 = 145 according to Definition 1 . 

6) AM 2X is received at the server proxy. This message also has arrived in order. As 
this message carries two tuples, it is split into two messages and is put twice in 
the queue, once as an action message corresponding to UM X and the other as an 
action message corresponding to UM 2 (in this case, this is the first action 
message received at the server corresponding to UM 2 ). The delivery time for 
the first copy is calculated as D'^M*,^ 100 + 10 + 37 = 147. The delivery 
time for the second copy, considered in isolation with respect to action messages 
corresponding to UM 2 , will be D 2 [AM 2X ) = 119 + 10 + 9 = 138. But the action 
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message delivery times need to be correlated with other action messages such 
that all action messages corresponding to update message UM X should be 
delivered before any action message corresponding to UM 2 is delivered. Thus 
D 2 i^AM] x ) is calculated as Max(147, 138) = 147. Also, the delivery time for 
AM\ 2 which is already in the queue is updated to be 
D ] ( AM\ 2 ) = 1 00 + 30 = 130. Assume that the current time is 1 45 . 1 30 is smaller 
than the current time and hence AM\ 2 is delivered right away. 

7) Once AM\ 2 is delivered to the server and is processed, the credit for removing 
AC 3 and adding AC 4 is given to P x . The state of the game is changed to S 3 
which consists of objects AC X and AC 4 . The update message UM 3 is sent to the 
players. Assume that the window sent is [f/M 3 ] . This means, the server proxy 
does not wish to receive any more action messages corresponding to UM l and 
UM 2 . As mentioned earlier, the decision about the window has to be made in 
some fashion, may be even with the help of communication between the game 
server and the server proxy. At time 147, two copies of AM 2l are delivered, 
both of which becomes no-ops as AC 3 has already been removed. 

Let us now extend the above example to show the effect of out-of-order reception 
of action messages. Refer now to Figure 10 with respect to the following discussion. 

8) AM\ 2 is received at the server proxy (and is out-of-order) and is put in the 
delivery queue. The delivery time is computed as 

D 3 (^M 2 3 2 ) = 145 + max(l0,15) + 5 = 165 based on Definition 3. Note that as 

AM\ 2 has been received out of order, it is possible to receive a message from 
P 2 with a reaction time smaller than 5 and hence the wait timeout of P 2 needs 
to be considered. Refer to the definition of Q set forth previously. 
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9) AM\ X is received at the server proxy (and is in-order) and is put in the delivery 
queue. The delivery time is computed as D 3 (AM? x } = 145 + 15 + 5 = 164. 

Again, the wait timeout of P 2 needs to be considered as the message currently 
in the queue from P 2 has arrived out of order. 

10) AM\ X is received at the server proxy (and is in-order) and is put in the 

delivery queue. Now, message AM 22 in the queue also becomes in-order. 
Using Definition 1, the delivery times of all the messages in the queue are 
computed as: 

D 3 [AMl x ) = 145 + 3 = 148 
D 3 (AM? } ) = 145 + 4 = 149 
D 3 (AM 3 2 ) = 145 + 10 + 5 = 160 

The delivery times for AM 2] and AM 3 } will be smaller than the current time 
(note that the current time is at least 150 as message AM 3 22 has been received 
with a reaction time of 5 in response to UM 3 which was sent at time 145). 
These messages will be delivered with P 2 getting the credit for removing AC X 
and adding AC 4 . In this case AM\ X will be a no-op. 

11) The update message UM 4 is sent to the players. At time 160, message AM\ 2 
will be delivered to the server and the credit for removing AC 4 will be given 
to P 2 . 

20 The present invention provides a framework called Fair-Ordering Service to 

achieve fairness in a distributed, client-server based, multi-player game environment. 
The framework consists of having proxies for both the game server and the game 
players, referred to as server proxy and player proxy, respectively. The server proxy is 
responsible for delivering players' actions in a fair order to the game server. This is 

25 achieved by tagging messages with extra information at the origin proxy, and 
processing the extra information at the destination proxy, keeping both the server and 



10 
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the players oblivious to the fair-order delivery process. This transparency allows the 
proxies to be used for a number of different game applications. 

Although the framework is kept independent of game applications, it is 
possible to use some application specific information to further optimize the fair 
5 delivery of messages, that is, deliver the messages even sooner than what has been 
proposed. The game application may also help in deciding some of the parameters of 
the proxy, for example, the maximum wait timeout after which to declare an action 
message from a player too late to be delivered to the game server, or the size of the 
window of update messages opened up by the server proxy. They can be treated as 

1 0 input parameters to a proxy's configuration. 

Fig. 1 1 shows an exemplary block diagram of a proxy device 110 according to 
the present invention. In general, the device includes at least two functional blocks, 
which operate in connection with a processor 120. A first block 130 is a queue where 
received transmissions are stored and wherein certain transmissions are reordered as 

15 has already been explained. A next block 140 is a memory device for storing 
instructions, for example in software, in order to carrry out the methodologies of the 
present invention. The proxy device also includes input and output ports 150, 160. 

For clarity of explanation, the illustrative embodiment of the present invention 
has been described as comprising individual functional blocks and/or boxes. The 

20 functions these blocks and/or boxes represent may be provided through the use of 
either shared or dedicated hardware, including, but not limited to, hardware capable of 
executing software. Use of the term "processor" should not be construed to refer 
exclusively to hardware capable of executing software. Further, the illustrative 
embodiment may comprise digital signal processor (DSP) hardware, read-only 

25 memory (ROM) for storing software performing the operations discussed below, and 
random access memory (RAM) for storing DSP results. Very large scale integration 
(VLSI) hardware embodiments, as well as custom VLSI circuitry in combination with 
a general purpose DSP circuit, may also be provided. 

To further illustrate the present invention, we categorize update messages. 

30 These are messages sent by the game server to the game players. There are two cases, 
one case is when there is only one update message, therefore, all action messages 
correspond to this update message. The other case is when there are multiple update 
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messages, therefore, it is not clear to which update message a particular action 
^message corresponds. Obviously case one is the degenerate case of case two. For case 
two, we need to use the "message split" mechanism, where at the player proxy, each 
action message is associated with a window of update messages, and for each update 
5 message, a reaction time is calculated. An action message is therefore inserted into 
multiple queues each corresponding to one update message in its window. 

Second, we categorize on action messages considering only one update 
message. We have three cases: 1) when action messages arrive in order and within 
their wait timeout periods, 2) when action messages arrive out of order but within 
10 their wait timeout periods, 3) when action messages arrive outside their wait timeout 
periods. Again, here case 3) is the most general case, it degenerates to case 2) and 
case 1). 

Third, we consider a sequence of update messages, and the correlation of 
action message delivery time. When a sequence of update messages are considered, a 
1 5 delivery time formula (X) is presented taking into account the delivery time for the 
last action message for the previous update message. This formula applies to cases 1), 
2) and 3) since 1) and 2) are degenerates of case 3). 

The invention further illustrates a method of separating the computation of the 
delivery time into three scenarios: 1) when action messages arrive in order and within 

20 their wait timeout periods, 2) when action messages arrive out of order but within 
their wait timeout periods, 3) when action messages arrive outside their wait timeout 
periods. When messages arrive in order and within their wait timeout periods the 
local delivery time of an action message at the server proxy should be calculated 
before being inserted to the delivery queue, and recalculated upon new action 

25 message arrival according to Definition 1. This delivery time guarantees that when an 
action message corresponding to an update message is delivered, no other action 
message corresponding to the same update message with a smaller reaction time may 
be in transit. 

When messages arrive out of order to order messages from a specific player 
30 and to determine whether all earlier messages sent by said player have arrived, the 
local delivery time of an action message at the server proxy should be calculated 
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before being inserted to the delivery queue, and recalculated according upon new 
action message arrival according to Definition 3. When messages do not arrive within 
wait timeout. - i.e. when not to accept any more action messages corresponding to a 
update message, the local delivery time of an action message at the server proxy 
5 should be calculated before being inserted to the delivery queue, and recalculated 
according upon new action message arrival and action message delivery according to 
Definition 3. Using this reasoning, we use the formula (X) combined with update 
message window, "message splitting" mechanism as the generic algorithm to 
implement in the framework. 

10 The foregoing description merely illustrates the principles of the invention. It 

will thus be appreciated that those skilled in the art will be able to devise various 
arrangements, which, although not explicitly described or shown herein, embody the 
principles of the invention, and are included within its spirit and scope. Furthermore, 
all examples and conditional language recited are principally intended expressly to be 

15 only for instructive purposes to aid the reader in understanding the principles of the 
invention and the concepts contributed by the inventor to furthering the art, and are to 
be construed as being without limitation to such specifically recited examples and 
conditions. Moreover, all statements herein reciting principles, aspects, and 
embodiments of the invention, as well as specific examples thereof, are intended to 

20 encompass both structural and functional equivalents thereof. Additionally, it is 
intended that such equivalents include both currently known equivalents as well as 
equivalents developed in the future, i.e., any elements developed that perform the 
same function, regardless of structure. 

In the claims hereof any element expressed as a means for performing a 

25 specified function is intended to encompass any way of performing that function 
including, for example, a) a combination of circuit elements which performs that 
function or b) software in any form, including, therefore, firmware, microcode or the 
like, combined with appropriate circuitry for executing that software to perform the 
function. The invention as defined by such claims resides in the fact that the 

30 functionalities provided by the various recited means are combined and brought 
together in the manner which the claims call for. Applicant thus regards any means 
which can provide those functionalities as equivalent as those shown herein. Many 
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other modifications and applications of the principles of the invention will be apparent 
to those skilled in the art and are contemplated by the teachings herein. Accordingly, 
the scope of the invention is limited only by the claims. 



